The Common Object Request Broker Architecture (CORBA) defines an architecture for distributed objects. The basic CORBA paradigm is that of a request for services of a distributed object. CORBA normalizes the method-call semantics between application objects that reside either in the same address space or remote address space. The CORBA standard defines a set of distributed services to support the integration and interoperation of distributed objects.
The CORBA standard specifies that there is an object request broker (ORB) through which an application interacts with objects. The ORB is a distributed service that implements requests to remote objects. The ORB locates the remote object on the network, communicates the request to the object, waits for the results, and, when available, communicates the results back to the requesting client. ORBs communicate with one another using the General Inter-ORB Protocol (GIOP).
ORB is a piece of middleware software that allows programmers to make program calls from one computer to another via a network. ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objects from different vendors so that they can communicate with each other via the ORB.
ORBs handle the transformation of in-process data structures to and from the byte sequence, which is transmitted over the network. This is called marshalling or serialization. The opposite operation, extracting a data structure from a series of bytes, is called unmarshalling or deserialization.
The CORBA standard allows for different versions of a class to exist at both the server and client side in a network system. In cases where there are different versions of a class, the server and/or the client may send and receive extra fields, which are redundant. For example, suppose that the server has version 2 of a particular class, class A, and that the client has version 1 of the same class, class A. If the client ORB (ORB in client) receives instance data for class A from the server ORB (ORB in server), then there may be some data that the client ORB cannot understand because its version of class A is different. In such situations, the CORBA standard provides a method to access the meta information (“meta call”) about the class version of the object it just received.
When the client ORB makes a meta call to the server ORB for class A, the server ORB will send a complete description of the class which includes details, such as the name of the class, names of the members of the class as well as the type code information of the class. The information is then used by the client ORB to unmarshal the data received and ignore the fields that it cannot understand (e.g., ignore those fields that are not contained in its version of class A). Despite the fact that the client ORB may not understand these additional fields, the server ORB continues to send these extra fields whenever an instance of class A is sent to the client ORB. As a result, unnecessary data is being exchanged, where the information may be large, such as when one of the fields is an object reference to a complex object graph. An object reference identifies the distributed object that will receive the request. An object graph refers to groups of objects that form a network through their relationships with each other (either through a direct reference to another object or through a chain of intermediate references). Such object graphs may be complex, such as when the group of objects contains an application object, with references to the windows, menus and their reviews, and other supporting objects.
Furthermore, while the client ORB receives information regarding the description of the class existing at the server, the client ORB does not make use of such information when it sends its class definition in response to a meta call from the server (server ORB sends a meta call to the client ORB in response to receiving instance data for a class from the client ORB that is different from its class definition). The class definition sent by the client ORB may include additional information, which unnecessarily increases the size of the transmitted data, especially if a field is an object reference to a complex object graph.
As a result, the client and server ORBs continue to send and receive these extra fields, which are redundant, which unnecessarily increases the size of data being transmitted thereby diminishing overall performance.